@ExtremeFiretop,

This PR is in response to a post from SNB Forum user vlord:

https://www.snbforums.com/threads/merlinau-v1-5-2-the-ultimate-firmware-auto-updater-webui-gnuton-support.91326/page-20#post-965308

I think it's a good idea to allow on-demand, manual F/W update checks when users select the menu option without the need to enable the automatic functionality.

The "Automatic F/W Update Checks" option is currently DISABLED

Allow manual F/W Update checks even when automatic checks are disabled

Note that if "Automatic F/W Update Checks" option is currently enabled, the new code is skipped and the execution flow is the same as before since the assumption is that the automatic functionality takes precedence.

@Martinski4GitHub

All great idea's will test them now that they are in dev :)
What happened to he had nothing more to add for the last release! ;) Hahahaha

Release 1.5.3 is in the air tonight. Can you feel it coming in the air tonight? Oh Lord!
-Phil Collins writing about MerlinAU

@Martinski4GitHub

All great idea's will test them now that they are in dev :)
What happened to he had nothing more to add for the last release! ;) Hahahaha

Release 1.5.3 is in the air tonight. Can you feel it coming in the air tonight? Oh Lord!
-Phil Collins writing about MerlinAU

LOL!! 😆😃😜 You've got excellent taste in music!!!! 👍👍

At the time, I had not caught up with the SNB Forums post WRT MerlinAU (I barely had time over the weekend). It was not until I had read vlord post and then thought about it that I decided to make the latest modifications. The other minor changes WRT version tag, I had them in my "back pocket" on my own development/test branch for some time, but I had completely forgotten about them since they were not adding any critical functionality.

Anyway, thanks for the review and, hopefully, you had some opportunity to test and validate the changes. But there's no hurry, so take your time, bud!!

🎶🎶 I've been waiting for this moment all my life... 🎶🎶 😉 LOL!!!

@Martinski4GitHub

Thank you for your kind words my friend! ;) I like to think I have a good mix of music taste hahaha
Now for the fun part!! I did my round of testing and I am a little confused as to what happened, I may need you to review with me.

Let's start with the good stuff!

1. The "help" page improvements are showing well:

2. Same with the "about" page:

3. Your improvements to allow manual update checks when auto checks is disabled, is working well also:

Now to move on to the "wth happened?" part.

1. When testing the above, I initially started the script after updating to the latest dev build; and disabled the auto update checks before existing as seen in the flow below:

2. Once I exited the script I modified my routers nvram values as seen in the screenshot and then restarted the script so it would start in a state with an "update available", and upon starting the script I was prompted to enable the cron jobs (as though it's a first install and the config file wasn't loaded) and upon saying no to enabling auto-updates, it loaded the menu without my password saved:

As you can see by the screenshots above I did have a password saved and did disable the auto cron jobs once in time, so why is it asking me to re-enable them and re-set my password?

I also can't uninstall it because our patch is mounted:

I also can't uninstall it because our patch is mounted:

Great catch!! I've submitted PR #510 for this particular problem.

@Martinski4GitHub

Thank you for your kind words my friend! ;) I like to think I have a good mix of music taste hahaha Now for the fun part!! I did my round of testing and I am a little confused as to what happened, I may need you to review with me.

....

Now to move on to the "wth happened?" part.

1. When testing the above, I initially started the script after updating to the latest dev build; and disabled the auto update checks before existing as seen in the flow below:

...
2. Once I exited the script I modified my routers nvram values as seen in the screenshot and then restarted the script so it would start in a state with an "update available", and upon starting the script I was prompted to enable the cron jobs (as though it's a first install and the config file wasn't loaded) and upon saying no to enabling auto-updates, it loaded the menu without my password saved:

As you can see by the screenshots above I did have a password saved and did disable the auto cron jobs once in time, so why is it asking me to re-enable them and re-set my password?

That's a very strange scenario that you ran into. It looks as if your configuration file was somehow "corrupted" or perhaps removed at some point, so that the MerlinAU script started out with a "default" configuration.

Did you double-check the contents of the configuration file after this problem occurred?
If so, did you find anything that was modified from your previous revision?

Are you able to recreate the same scenario fairly consistently?
If not, I'm not sure where to start looking for possible culprits, but if you can recreate it, hopefully, we should be able to track down the root cause.

P.S.
I came from work about an hour ago and saw your messages after taking a short nap and getting ready for dinner.
Excellent catches, BTW. The above scenario is particularly very "odd" since, for my own testing & validation, I did exactly the same thing you did WRT changing the NVRAM variables manually to make the code execute the F/W update check script via the menu option.

@Martinski4GitHub
Thank you for your kind words my friend! ;) I like to think I have a good mix of music taste hahaha Now for the fun part!! I did my round of testing and I am a little confused as to what happened, I may need you to review with me.
....
Now to move on to the "wth happened?" part.

1. When testing the above, I initially started the script after updating to the latest dev build; and disabled the auto update checks before existing as seen in the flow below:

...
2. Once I exited the script I modified my routers nvram values as seen in the screenshot and then restarted the script so it would start in a state with an "update available", and upon starting the script I was prompted to enable the cron jobs (as though it's a first install and the config file wasn't loaded) and upon saying no to enabling auto-updates, it loaded the menu without my password saved:

As you can see by the screenshots above I did have a password saved and did disable the auto cron jobs once in time, so why is it asking me to re-enable them and re-set my password?

That's a very strange scenario that you ran into. It looks as if your configuration file was somehow "corrupted" or perhaps removed at some point, so that the MerlinAU script started out with a "default" configuration.

Did you double-check the contents of the configuration file after this problem occurred? If so, did you find anything that was modified from your previous revision?

Are you able to recreate the same scenario fairly consistently? If not, I'm not sure where to start looking for possible culprits, but if you can recreate it, hopefully, we should be able to track down the root cause.

P.S. I came from work about an hour ago and saw your messages after taking a short nap and getting ready for dinner. Excellent catches, BTW. The above scenario is particularly very "odd" since, for my own testing & validation, I did exactly the same thing you did WRT changing the NVRAM variables manually to make the code execute the F/W update check script via the menu option.

I did try to recreate the issue last night right away before reporting it and was unable too. So I'm not exactly sure what happened. But I'm going to try and spend some more time today to see if I can somehow trigger it again or narrow it down as I didn't spend much time on it yesterday.

My gut feeling tells me the configuration file also had some kind of issue and caused the above errors. Sadly I did not think to check the configuration file before "reconfiguring it" since I was still in the "test mode" for your above PR. My goal at the time was just validate these changes so I powered through, without realizing to check the configuration file before reconfiguring.

AH!

@Martinski4GitHub

I FOUND THE CAUSE!!!! I just recreated the issue... Je suis a Genuis and also a bit dumb at the same time ;) Give me a moment to collect all the screenshots and compose my thoughts

@Martinski4GitHub

The "problem" was in the CheckForMinimumRequirements function

Here is the flow to re-create the problem:

1. Update the script and disable the auto update checks:

2. Next, modify your nvram (as we always do to test).
But accidently set something below the minimum version supported this time:

3. Next, run the script, when it says it's below the minimum version. Choose not to uninstall!!!:

4. Next, set something above the minimum version and re-run the test, you will see the behavior of the "corrupt" settings file:

The issue is that the function CheckForMinimumRequirements is set to delete the file for some reason, even if we choose not to uninstall the script. (Not expected behavior?)

If I remove the line 9571 from the function: rm -f "$CONFIG_FILE" then all works as expected if i choose not to uninstall the script in that instance. Is it safe to remove? I would think so, considering within the check we do DoUnInstallation if the user selects to uninstall which would wipe out the configuration file as expected. I don't think we need the additional delete without uninstalling the script

Created PR: #511 with the suggestion for review

That flow I described for the issue above is exactly what happened to me yesterday, it's just at the time it was NOT expected behavior that the file would be deleted if I choose to "not" uninstall the script. I expected "oh whoops wrong version... Too low" set something else higher and move on. I didn't expect to have to reconfigure from zero without uninstalling, which is what caused the issue report

That flow I described for the issue above is exactly what happened to me yesterday, it's just at the time it was NOT expected behavior that the file would be deleted if I choose to "not" uninstall the script. I expected "oh whoops wrong version... Too low" set something else higher and move on. I didn't expect to have to reconfigure from zero without uninstalling, which is what caused the issue report

Yes, the change in PR #511 fixes the workflow you described above. But at first, I was puzzled because in your original post about the problem, you didn't mention anything at all about getting prompted to uninstall MerlinAU due to the F/W version being below the minimum supported. That was a significant and relevant detail, but you omitted it because you didn't think it was important at the time, LOL!!!

That's a classic mistake users often make when reporting a problem; they describe only what they believe is important and relevant to the problem, while omitting other details that may contribute to and/or lead to the actual problem.

Anyway, glad the solution was very simple. The problem would not affect regular users, of course, since the testing scenario (changing NVRAM key values) used for troubleshooting and debugging purposes is not something regular users would do on their own routers.

That flow I described for the issue above is exactly what happened to me yesterday, it's just at the time it was NOT expected behavior that the file would be deleted if I choose to "not" uninstall the script. I expected "oh whoops wrong version... Too low" set something else higher and move on. I didn't expect to have to reconfigure from zero without uninstalling, which is what caused the issue report

Yes, the change in PR #511 fixes the workflow you described above. But at first, I was puzzled because in your original post about the problem, you didn't mention anything at all about getting prompted to uninstall MerlinAU due to the F/W version being below the minimum supported. That was a significant and relevant detail, but you omitted it because you didn't think it was important at the time, LOL!!!

That's a classic mistake users often make when reporting a problem; they describe only what they believe is important and relevant to the problem, while omitting other details that may contribute to and/or lead to the actual problem.

Anyway, glad the solution was very simple. The problem would not affect regular users, of course, since the testing scenario (changing NVRAM key values) used for troubleshooting and debugging purposes is not something regular users would do on their own routers.

Exactly.

It was thought to be a irrelevant detail so I wasn't sure what happened originally.
However after attempting to recreate it "without the irrelevant detail" I realized I couldn't cause the problem anymore which made me reconsider what was and wasn't relevant.

I attempted to recreate the flow exactly how I remembered it yesterday. Down to my mistake in changing the nvram values, and bamn, the "issue" showed it's head again.

That allowed me to narrow it down to the functions at play from there.
While it wouldn't cause an issue for our users, we may as well line it up with our expectations and actually "make it an irrelevant detail" for the future if this mistake ever happens again hahaha 🤣